This invention relates generally to distributed computing environments and particularly to availability management of resources in a distributed environment. More particularly, the present invention relates to methods of xe2x80x9clockingxe2x80x9d distributed environment resources to prevent inappropriate access to such resources. More particularly still, the present invention relates to server-side management of locks within the WebDAV protocol.
Distributed computer environments, such as computer networks, provide significant advantages to multiple computer clients or users. In particular, distributed environments allow multiple clients to actually share many different computer resources including both hardware and software resources. Sharing software-related resources provides many known benefits, such as the fact that only one such resource needs to be created, updated and maintained.
The Internet is one particular example of a distributed environment that provides access to a considerable number of software resources, which are available to practically any client computer system having Internet capabilities. One portion of the Internet is known as the World Wide Web which is a generally a system of Internet servers that house software related resources that are formatted in a particular manner, such as with HTML (HyperText Markup Language). The protocol for accessing these particular resources is known as the HyperText Transfer Protocol or HTTP. It should be noted however that not all Internet servers are part of the World Wide Web.
With recent advances, clients may effectively author resources on a server system from client systems over distributed networks, including the Internet. For instance, the WebDAV protocol or standard, which stands for the World Wide Web Distributed Authoring and Versioning standard, referred to herein as simply xe2x80x9cDAV,xe2x80x9d provides a set of headers and methods which extend HTTP to provide capabilities for managing properties, namespace and other items from a client system in order to allow client computer systems to access server-side resources for the purpose of editing those resources. Proposed Standard RFC 2518, which is a document written by the IETF and approved by the IESG, published February 1999, describes DAV in more detail.
As part of the DAV standard, server computer systems provide various services in managing the various access requests made by clients. One particular service relates to controlling when a resource is available for use by a client. That is, DAV provides methods that allow a client to lock a resource when using that resource so that subsequent users may not access that resource during that time. This locking scheme helps prevent the xe2x80x9clost updatexe2x80x9d problem associated with two or more users modifying a resource simultaneously such that editions are inadvertently lost. Additionally, the locking scheme provides an ability to lock two resources that may be needed to perform a file-management type function. For example, assuming a resource exists in one folder, yet the owner wants to move the resource into another folder, i.e., the destination folder. In such a case the client needs to lock both the resource and the destination folder. Locking both resources allows for the operation to proceed without conflicts.
Although the locks are helpful in preventing the lost update problem, the present locking system implemented in DAV is unsatisfactory with respect to the allocation of these locks. For instance, a DAV lock only covers, at most, one resource tree. That is, the lock request itself typically includes a uniform resource identifier (xe2x80x9cURIxe2x80x9d) and a depth. The depth indicates the number of levels of sub-elements or children of the resource identified by the URI to be locked. Unfortunately, if the client system needs to lock multiple URIs that are not in a parent child relationship, multiple lock requests are required. In return, the client system receives multiple lock tokens or cookies representing the locks on the various resources. Since many operations typically involve several different and unrelated resources, the request, receipt and management of the multiple locks increases the overhead involved.
Moreover, requesting multiple locks is not a satisfactory solution since some locks may be granted while others are not which negatively affects the atomicity of a requested operation. An atomic operation or the atomicity of an operation, relates to an operation that must be performed entirely or not at all. Since lock requests are typically associated with a particular access or command request, atomicity is typically required. Therefore, the partial granting of a selective few of the locks is not acceptable.
Additionally, if two or more separate client processes attempt to lock the same resources, a potential deadlock situation may occur, where each locks one of the resources but prevents the other(s) from locking all the resources. A deadlock situation precludes lock success for each of the processes. One solution to this problem involves a server-side utility that monitors lock requests and attempts to xe2x80x9crememberxe2x80x9d whether a lock request has been granted to a client process that is now requesting a subsequent resource. Recognizing that a client process is requesting a subsequent resource provides the server the ability to anticipate potential deadlock situations before they occur. Unfortunately, a significant amount of overhead is required to store information related to all previously granted lock requests, and the client that requested the lock.
It is with respect to these and other considerations that the present invention has been made.
The present invention solves these problems by creating and enabling the use of a new lock type request relating to multiple locks, i.e., multiple resources. The method and system creates and maintains lock properties for a resource or object in a distributed environment.
In accordance with certain aspects, the invention relates to a system and method of locking resources that receives a request to access more than one resource, wherein the request originates from a requesting client computer system and based on this request locks the requested resources. Upon locking the resources, the system and method provides a lock token related to the created lock to the requesting client computer system. The system and method may either create a new lock object for the resources or update and existing lock object. Thus, a plurality of resources may be locked based on one request. Additionally, since one request included an indication that more than one resource is to be locked, the receiving system can anticipate and resolve potential deadlock situations.
In accordance with other aspects, the system and method determining whether the resources are locked by one or more other client computer systems and locks the resources only if no existing lock conflicts with the type of access requested or the type of lock requested. When an existing lock is to be modified, the system and method may also determine whether the resources are locked by one or more other client computer systems or whether the requesting application is the lock owner and update a lock only if no existing lock conflicts with the type of access requested or the type of lock requested and if the requesting application is the owner. Further, prior to creating or updating the lock, a determination may be made as whether the other resources should be locked; and if other resources should be locked; then the system and method locks those resources.
In accordance with still other aspects, the present invention relates to a lock management system that has a receive module for receiving a request to lock a plurality of resources; a locking module for locking the requested resources; and an allocation module for allocating a lock token related to the requested resource. The lock management system may create or update a lock object that locks the plurality of resources. The lock object itself is a data structure having a resource list that identifies the resources locked by the lock object. The resource list may have universal resource identifiers (URIs) for each of the resources locked by the lock object.
The present invention also relates to a system and method for locking a resource that receives a request to access a particular resource, wherein the request originates from a requesting client computer system and then determines whether the resource is locked. Upon determining that the resource is locked, the system and method further determines whether an additional lock object may be associated with the resource and if so, creates another lock object and provides a lock token related to the created lock to the requesting client computer system. Additionally, the system and method allows for requesting application programs to request that only a predetermined number of additional lock objects be associated with the resource.
The invention may be implemented as a computer process, a computing system or as an article of manufacture such as a computer program product. The computer program product may be a computer storage medium readable by a computer system and encoding a computer program of instructions for executing a computer process. The computer program product may also be a propagated signal on a carrier readable by a computing system and encoding a computer program of instructions for executing a computer process.
A more complete appreciation of the present invention and its improvements can be obtained by reference to the accompanying drawings, which are briefly summarized below, to the following detail description of presently preferred embodiments of the invention, and to the appended claims.